Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
id AA28916; Tue, 23 Nov 1993 18:16:23 -0500
Received: by usage.csd.unsw.OZ.AU id AA02215
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 24 Nov 1993 10:16:10 +1100
Received: by atlas (4.1/1.35)
id AA25460; Wed, 24 Nov 93 10:16:23 EST
Message-Id: <9311232316.AA25460@atlas>
From: paul@atlas.abccomp.oz.au
Date: Wed, 24 Nov 1993 10:16:22 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: rcq@ftp.com, Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
Subject: Re: non-blocking lingering close
Thus expounded Bob Quinn on Nov 23, 3:50pm:
/--------------------
|Hi Paul!
|
|> "violation of the API"? APIs are defined to be what is found to be useful,
|> and/or in this case largely compatible with BSD code. APIs aren't violated,
|> they are defined.
|
|One of the great advantages of the Windows Sockets API is that
|it hides low-level details. APIs are indeed defined to be useful,
|but simplicity has great benefits. Exposing low-level details
|complicates an API.
Agreed.
| If its unnecessary, it's a violation.
Thats a bit strong, isn't it? If its unnecessary, its unnecessary, but it isn't broken, and simply "not using" an unnecessary feature is enough to shield you
from the consequences. I guess I associate "violation" with phrases/words like
"abomination", "blight on the planet", and other fire-and-brimstone concepts!
In an ideal API, every part in it is presumably defined because at least
someone thought it necessary. That doesn't mean there aren't other features
that are necessary, but no-one has thought of them yet. Not that I'm saying
FIONWRITE is such a feature, of course!
It could be argued that send() and recv() are unnecessary (and hence
"violations"), since exactly the same effect can be obtained using
sendto() and recvfrom() with NULL address arguments.
|Detecting incoming data with FIONREAD is very different than
|detecting incoming acknowledgments with FIONWRITE.
I didn't want to detect incoming ACKS - that is protocol-specific to TCP,
and the sockets paradigm is not. I want to know the length of the outbound
data queue, which is not, as far as I know, a concept specific to any
stream protocol. For TCP, it is the sum of the data not-yet-sent and the length
of the retransmission queue, but the application doesn't need or want to
know how its calculated or stored.
|One side initiates the close of a TCP socket, not both. If you
|have called shutdown(how=1), it's valid to expect recv()=0 to
|indicate the completion of a graceful close. Otherwise you have
|a seriously broken client/server pair.
Rubbish. Its perfectly possible for both sides to close their sending-side
simultaneously, or at least before they are aware the other end has done so.
Its not the common case, but its possible. In general, either side may shutdown
their sending, to indicate "I won't send any more data". If the other
end ever reciprocates (and its not guaranteed), yes you will get recv()=0
eventually. If the other end has already closed its end, and is just accepting
all the incoming data up to your FIN, you may well read the recv()=0 before
the other end has accepted your outgoing data. In short, the world is not
limited to using TCP in "client/server" pairs.
This has gotten a bit out of hand, Bob - lets take our religious differences
to email, and concentrate on the technical issues here!
|
|> Am I correct that a closesocket() with linger set on (for a long time)
|> should block until the socket exits TIMEWAIT (if it is the first
|> FIN sender)?
|
|No. And it doesn't matter what the timeout length is. After
|initiating the close, a blocking closesocket() returns immediately
|after it receives the TCP <ACK><FIN>. In other words, closesocket()
|returns at the point the TCP connection enters the TIMEWAIT state.
|
|The socket is invalid after the return from closesocket(). But if
|it just completed a graceful close (that it initiated), the TCP
|connection still has some life to it. It can send another <ACK>
|if the other side missed the first one and sends another <FIN>.
|The port used cannot be bound by another socket until this TIMEWAIT
|state expires.
Oh! I have been assuming that a blocking lingering closesocket() must block
until the socket is fully closed (i.e. right through TIMEWAIT), because
only then can you bind() another socket to the same port (without setting
SO_REUSEADDR). There are certainly many points in Jim Gilroy's WSAT
scripts where he assumes you can create an identical TCP connection
(same addresses/ports) immediately after closesocket() returns.
How is this different, then, from a non-blocking graceful closesocket()?
At least in the non-blocking graceful close your data will be correctly sent
if possible, no matter how long it takes, whereas with the blocking graceful
close you have no guarantee your data will be sent, because of the possibility
of the timeout occuring.
>From an application's point of view, picking a timeout value applicable
for all the different possiblities of remote host speeds and path speeds that
might occur, so that the application works well over ethernet or 300 baud
packet radio and still closes connections off in a timely manner without
aborting the close process prematurely, is fraught with difficulty, and offends
me more than being able to find out the amount of outstanding data (which
BTW could be used to judge the average link speed, and hence allow more
sensible timeout values for blocking closesocket()s to be chosen!).
Bob, any thoughts on the other message I sent, about matching incoming
SYN packets with aborted connections?
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From paul@atlas.dev.abccomp.oz.au Tue Nov 30 11:30:36 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
id AA04606; Tue, 30 Nov 1993 03:02:44 -0500
Received: by usage.csd.unsw.OZ.AU id AA27113
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 30 Nov 1993 16:20:20 +1100
Received: by atlas (4.1/1.35)
id AA13318; Tue, 30 Nov 93 16:30:36 EST
Message-Id: <9311300530.AA13318@atlas>
From: paul@atlas.abccomp.oz.au
Date: Tue, 30 Nov 1993 16:30:36 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: winsock-hackers@sunsite.unc.edu
Subject: newsgroup -> email gateway problems?
I am seeing many more messages inthe alt.winsock newsgroup than I am from
the winsock mailing lists - messages seem to be gated form the mailing list to
the newsgroup OK, but news postings don't seem to be gated back to
the mailing list. Has anyone else noticed this?
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From paul@atlas.dev.abccomp.oz.au Tue Nov 30 11:28:24 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
id AA04634; Tue, 30 Nov 1993 03:03:09 -0500
Received: by usage.csd.unsw.OZ.AU id AA27019
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 30 Nov 1993 16:18:14 +1100
Received: by atlas (4.1/1.35)
id AA13300; Tue, 30 Nov 93 16:28:24 EST
Message-Id: <9311300528.AA13300@atlas>
From: paul@atlas.abccomp.oz.au
Date: Tue, 30 Nov 1993 16:28:24 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: winsock-hackers@sunsite.unc.edu
Subject: Multiple connect()s with SOCK_DGRAM sockets?
What is the feeling of the community in allowing multiple connect() calls
on SOCK_DGRAM sockets? I have several conflicting points either way:
1) The Winsock 1.1 manual does not mention the possibility of calling
connect() again to change the desired destination endpoint on UDP
sockets.
2) My Sun's man-page for connect() indicates that a SOCK_DGRAM socket can
be "un-connected" by calling connect() with an invalid address -
presumably you can then call connect() with a different valid address.
3) Jim's WSAT scripts seem to want to do exactly this, using a destination
sockaddr_in with all fields, including sin_family, set to 0. The Winsock
spec. should fail these calls with WSAEAFNOSUPPORT, although Jim
assumes they will succeed.
4) Doing the same thing on the Sun (all fields, including family, 0)
caused that connect() call to core dump !
5) Douglas Comer, in "Internetworking with TCP/IP Vol. 3", section 8.17,
says that once a UDP socket is connect()ed, it can never again be used
to receive datagrams from arbitrary clients - it can never be
un-connected.
Since I've been informed more than once that the aim is "BSD compatibility",
and if the Winsock spec differs from BSD behaviour, the BSD behaviour is what
should be followed, I would like to propose some standard behaviour for
Windows Sockets implementations, possibly with appropriate text added to the
next specification, or any addendum to the current spec. (Wasn't there going
to be a document with examples and explanations of some points, for those of
us unable to get to the winsock-a-thons for the FD_CLOSE wars and similar?)
1) A connected SOCK_DGRAM socket can be "dis-connected" by calling
connect() again with a destination 'name' consisting of address and
port containing all zeros, and a valid family for the socket
(i.e. "AF_INET / 0 / 0.0.0.0").
2) A connected SOCK_DGRAM must be dis-connected using this method before
it can be re-connected again, to the same or different destination
address, otherwise an error code of WSAEISCONN will be returned
(just like should happen now).
This should retain full compatibility both with the current specification and
with BSD sockets.
Comments anyone? I would really like to hear how the various implementations
currently behave in this regard, and what everyone thinks is a reasonable
interpretation of the 5 conflicting points listed above.
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From rrealmut@b30po1.pcmail.ingr.com Tue Nov 30 00:58:00 1993
Received: from pcout.pcmail.ingr.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
id AA28635; Tue, 30 Nov 1993 09:58:01 -0500
Received: from hubsmp2.pcmail.ingr.com by pcout.pcmail.ingr.com (5.65c/1.921207)
id AA01726; Tue, 30 Nov 1993 08:59:12 -0600
Received: by hubsmp2.pcmail.ingr.com with Microsoft Mail
id <2CFB7BD4@hubsmp2.pcmail.ingr.com>; Tue, 30 Nov 93 08:59:00 PST
